home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio / Ham Radio CD-ROM (Emerald Software) (1995).ISO / misc / hamdsk1 / fwdhdr.doc < prev   
Internet Message Format  |  1987-01-07  |  11KB
  1. From:  Norm Sternberg-W2JUP
  2. Subj:  pbbs message headers
  3.  
  4. Here are thoughts on the "headers" subject.  First, let's put "message 
  5. headers" in perspective by looking at the Commission's recent statement in 
  6. Report No. DC-645, dated 10/9/86:
  7.  
  8. "Although it acknowledged assurances of safeguards by the ARRL for the AX.25 
  9. packet protocol, the FCC noted that control operators capable of monitoring 
  10. such transmissions must alert the control operator of any intermediate 
  11. retransmitting station, under automatic control, of any station misuse so that 
  12. corrective action can be determined."
  13.  
  14. To respect the FCC's directives and ensure minimum capability of PBBSs and 
  15. network node to comply with FCC requirements, we'd best take a hard look at 
  16. the real world:
  17.  
  18. 1. THE ORIGINAL W0RLI/WA7MBL FORMAT COMPLIES - LET'S STAY WITH IT FOR NOW!
  19. 2. DESIGN NEW HEADERS BASED ON NEED, FUNCTION AND LOGIC - NOT 'PRETTY PRINT'.
  20. 3. DESIGN NEW HEADERS JOINTLY WITH CODE AND SWITCH DEVELOPERS. 
  21. 4. DESIGN NEW HEADERS FOR MACHINE-READABLE ROUTING TABLE GENERATION 
  22. 5. LEARN FROM COMMON CARRIER/PTT NETWORKS - DON'T RE-INVENT THE WHEEL!
  23.  
  24. Some basic assumptions:
  25. 1. The main purpose of headers is to service or "track" messages. 
  26. 2. Messages may require tracking back to originating station. 
  27. 3. Messages may also require tracking back to first entry node PBBS or switch.
  28. 4. The identity of both the originating station and the 'network access' 
  29.    station and its message number may be required to satisfy possible FCC 
  30.    traceability on third-party or other questions of legality or suitability 
  31.    of traffic. 
  32. 5. Date/time data is probably not needed for tracing message flow.
  33. 6. Lengths of fields can be fixed, or delimiters can be used for machine 
  34.    readability.
  35.  
  36.    The common carriers have dealt with headers for over a century, from 
  37. Western Union to today's International Record Carriers.  There's a parallel to 
  38. our packet radio networks.  Their message header formats are established by 
  39. the CCITT, the same agency that gave us Recommendation X.25. 
  40.    These commercial systems have one thing in common with us; automatic 
  41. store-and-forward message handling between "telegraph offices" (our nodes and 
  42. PBBSs).  They also have headers prepended to each message by each serving 
  43. office or node. 
  44.    Let's look at their criteria for message headers and try to learn from 
  45. their successful methods. 
  46.    Here are the items they require in their message headers.  
  47.    "Following the transmission of the numbering line and pilot line (if 
  48.    required) the various parts of the preamble line shall be transmitted in 
  49.    the following order: 
  50.     1.  The name of the office of origin 
  51.     2.  The number of words 
  52.     3.  The date and time of handing in of the telegram 
  53.     4.  Any service instructions" 
  54.    "When automatic retransmission of telegrams is required between offices in 
  55.    the network, the required format includes: 
  56.     1.  The destination indicator 
  57.     2.  The priority and tariff indicator 
  58.     3.  The origin indicator 
  59.     4.  The number of chargeable words 
  60.     5.  A customer identification group 
  61.     6.  The service indication 
  62.     7.  The address" 
  63.      (F.31, F Series of Recommendations of the CCITT. 
  64.  
  65.    In discussing the message header format question with colleagues at various 
  66. IRCs (WU, MCI, RCA, ITT, DPB, several PTTs) some conclusions were drawn as to 
  67. what's important and the relative order of importance in the header. 
  68.    1.   Main purpose of a message header: show where message originated, when, 
  69.         how and by whom it was handled. 
  70.    2.   Servicing tracing and routing is impossible without these as minima. 
  71.    3.   Message identification by sender's identifier is first priority for 
  72.         tracing message flow or servicing enquiries.  (The "sender" is the 
  73.         station that put the message into the network; the manual keyboard 
  74.         operator who wrote the original message.) 
  75.    3.   Require identification of all stations that handled the message and 
  76.         their message number.  (These are the PBBSs, nodes and switches that 
  77.         have actually manipulated the data.) 
  78.    4.   The date/time of forwarding by intermediate stations is least 
  79.         important traceable information.  Main value in early days of packet 
  80.         radio to show how long it took to traverse the network.  In terms of 
  81.         servicing enquiries, relatively unimportant. 
  82.    5.   Real goal of any redesign: headers that can be "read" by any serving 
  83.         automatic system to automatically set it's own routing tables.  This 
  84.         is typically accomplished in ARPANET.  Requires redesign of the RLI 
  85.         and MBL codes; possible if everyone agrees on format. 
  86.    6.   Message header formats now being used burden our systems with 
  87.         excessive overhead; need streamlining urgently.  
  88.    7.   Comments on new format proposed by K3MC:
  89.         (a)  Suggested standard pays too much attention to the "received/sent" 
  90.              date/time data - information of least value to the network except 
  91.              to satisfy curiosity. 
  92.         (b)  Failure to identify the originating manual station by callsign 
  93.              makes it impossible to trace message back sender, especially if 
  94.              the first node "kills" the message after forwarding it.  
  95.         (c)  Identity of sender must be carried through the network to satisfy 
  96.              FCC requirement.
  97.         (d)  Sender's message should be numbered by node at which message 
  98.              enters network.  Numbering should be carried through the network. 
  99.         (e)  Unless points (b), (c) and (d) are met, messages cannot be 
  100.              serviced in backwards direction; entire concept of message header 
  101.              becomes moot or questionable. 
  102.         (f)  Identification of switching nodes and PBBSs is less important 
  103.              than identifying the originator. 
  104.         (g)  Nodes should be identified by callsign only.  Location is 
  105.              irrelevant once nodes are set as part of network. 
  106.         (h)  Geographical locators or grid codes are irrelevant to the 
  107.              network. 
  108.         (i)  Manual users requiring information on routing/addressing should 
  109.              be given lists of PBBSs/nodes/callsigns/locations rather than 
  110.              burden the network with the data that the serving nodes already 
  111.              have in their routing tables. 
  112.         (j)  Question of fixed-length fields versus variable-length fields and 
  113.              relative positions in header is unimportant providing that field 
  114.              sizes, sequences and contents are standardized. 
  115.         (k)  Once all parties agree on efficient header format, node software 
  116.              (PBBS and switches) should be hard-coded to make compliance 
  117.              mandatory. 
  118.         (l)  Node software should be redesigned to automatically generate 
  119.              message routing tables based on data in received message headers. 
  120.         (m)  Network community should give urgent consideration to adaption of 
  121.              a better form of addressing, possibly based on Gordon Beattie's 
  122.              (N2DSY) suggested "AX.121" addressing methods.  Not necessarily 
  123.              applied to manual keyboard users.  First applied to network nodes 
  124.              and message servers. 
  125.  
  126. In summation, the consensus is this: 
  127.    1.   Header formats in original W0RLI code and WA7MBL compatible code 
  128.         generally satisfy FCC requirements and are probably best immediate 
  129.         approach if observed by all nodes and message servers in network. 
  130.    2.   Header variations based on "personal preferences and opinions" of node 
  131.         operators is probable cause of trouble; standardization is defeated 
  132.         and overhead is uncontrollable. 
  133.    3.   Immmediate need to modify PBBS code to list received date/time ONLY and
  134.         DELETE "sent date/time". 
  135.    3.   Format suggested is the following record and fields: 
  136.  
  137. $p/W2JUP-4/$M/Farmingville/NY/$J$K/r 
  138.  
  139. (Note: slant bars are field delimiters.)  
  140.  
  141. Format for existing PBBS service would be:
  142.   [Sender_call]      maximum field  9 bytes (WX1XXX-nn)
  143.   [PBBS/Node_call]      "      "    9   "       "
  144.   [PBBS/Node_Msg #]     "      "    5   "
  145.   [PBBS_City]           "      "   20   "
  146.   [PBBS_State]          "      "    2   "
  147.   [Ryymmddhhmm]         "      "   10   " 
  148.   [Time_Zone]           "      "    1   "
  149.   [Optional_ZIP]        "      "    9   "
  150.   [Optional_Grid]       "      "    6   "
  151.  
  152. For example, a message placed in my PBBS by a manual user and forwarded by "n" 
  153. PBBSs to the west coast might look like this:
  154.  
  155. W1XXX/WB7DCH/1234/Ecumclaw/WA/8611132300z
  156. W1XXX/KD6SQ/7654/RanchoCucamonga/CA/8611131855z
  157. W1XXX/W5XO/4567/Gausse/TX/8611131744z
  158. W1XXX/K4TKU-1/2345/Miami/FL/86111311513z
  159. W1XXX/W2HPM/277/Farmingville/NY/8611130957r
  160. W1XXX/W2JUP-4/4984/Farmingville/NY/8611122332r
  161.  
  162.    The fact that the columns don't line up neatly is irrelevant.  Any decent 
  163. software writer can code a parser to delete leading and trailing spaces, or 
  164. insert them as required.  
  165.    The important thing: send MEANINGFUL AND REQUIRED data - not useless extra 
  166. spaces, commas, etc.  Things like "From", "de", "Rec'd", "Sent", "@", "VIA", 
  167. "R:-", "S:-" "z", grid locators, latitude/longitude, can ALL be eliminated 
  168. once field content, size and sequence are fixed.  Serious coding can reduce 
  169. header length further when we reach the point of machine-readable data.  
  170. Clever program design can eventually achieve a single-line header that does it 
  171. all. 
  172.    Let's not confuse things introducing different variables with less 
  173. efficiency.  Hope this stimulates more thinking on the subject.  Regards to 
  174. all. 
  175.  
  176.  
  177. -----------------
  178. The above message was recieved some time ago from Norm, and I have edited
  179. it slightly.
  180.  
  181. My only comment about Headers was to keep them short and to get the
  182. un-needed "Sent time" out of them.
  183.  
  184. I would not be opposed to a format similar to:
  185.  
  186. R:8612310123z <K7PYK #1234 @WA7MBL (!801) [Logan, UT]
  187.  
  188. The R: would identify it as a header as opposed to text.  The
  189. < for from, # for msg number, @ for BBS fowarding, (! to indicate
  190. area code, and brackets for local optional junk would make it easy
  191. to parse by computer (and match some current message headers plus
  192. the current method of entering a message.)  It would also be easy
  193. to read by the message recipient.  (One small problem with a format
  194. with no "useless extra data").  Also, it should be easy to find the
  195. @BBS to address a return message to.
  196.  
  197. Jeff, WA7MBL
  198.